聊聊路边停车收费系统的架构：为什么我们选微服务，不选单体
做了快十年的城市智慧交通项目，我经手过不下二十个城市的路边停车收费系统改造。早些年大家图省事，清一色上单体架构——一个 WAR 包丢进 Tomcat，后台管设备、管订单、管收费、管报表全搅在一起。但最近这五年，但凡日均泊位超过 5 万个的项目，我都会劝客户坚决走微服务。不是追风口，是踩过的坑足够多，以至于再看到有人拿单体硬扛路边停车场景，我都替他们捏把汗。
先说路边停车这个业务本身。它和商场地下车库完全两码事。路边的设备极其碎片化：地磁、视频桩、高位相机、手持 POS、巡检车，每家厂商协议都不一样；网络环境是公开的市政道路，4G/5G 信号飘忽，设备离线率是常态；更麻烦的是，收费规则跟着行政区走，A 区首半小时免费、B 区夜间封顶 10 块，节假日还可能临时调价。单体系统要把这些全塞进一个进程，任何一处规则改动都得全量发版，半夜停系统升级，第二天早高峰交警和车主能把你电话打爆。
我们去年落地的中部某省会项目就是个典型。一期选了微服务，拆成了五个核心域：设备接入网关、泊位状态服务、计费引擎、支付清结算、运营监控。设备接入网关单独扛 MQTT 和私有协议解析，就算某个相机厂商固件出 bug 狂发脏数据，也只是网关重启，不影响背后计费。计费引擎做成独立服务后，物价局调价只需改配置中心推送，不用动其他模块。上线八个月，系统可用性 99.95%，而他们隔壁市同期上的单体系统，因为一次费率脚本错误，回滚耗时 40 分钟，直接引发千余笔错单投诉。
有人会说，微服务运维复杂、链路追踪麻烦。这话不假。但我们这类系统面对的是市政级并发：早高峰同时入位可能上万笔，单体数据库连接池一撑爆就全僵。微服务起码能按域隔离资源，支付服务压力大就单独扩副本，设备网关没必要跟着吃内存。用我们架构组的话说，“单体是把所有鸡蛋放一个篮子，还非得在车流里颠簸”。
当然，微服务不是银弹。小县城两三千个泊位，搞微服务纯属脱裤子放屁。我们内部有个红线：日订单低于 5 万、接入设备类型少于 3 种，直接单体最快。但凡超出这个体量，越早拆越主动。
最后说句实在的，路边停车系统最终卖的不是技术，是“车主扫码就走、城管后台看得清”的体感。微服务让我们团队能把每个域交给最懂的人——协议老手守网关，财务背景的同事盯清结算。这种分工在单体里是做不到的。架构没有绝对优劣，但在城市级路边停车这个泥泞又复杂的战场，微服务确实是被现实揍出来的最优解。
微信号：18581869297